Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1991/91-08

Text File | 1995-12-31 | 112KB | 3,145 lines

Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: Elements of C++ in THINK C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 25
Date: 2 Aug 91 05:04:41 GMT
X-Phone: [phone] x115


Date: Tue, 16 Jul 91 07:12:36 EDT
From: [e-mail] (Mark Gross)

Subject: Think C vrs of Elements of C++ Macintosh Programming

I have finished working through Dan Weston's book
"Elements of C++ Macintosh Programming"implementing many
of its class libraries using THINK C4.05.  I've made some
changes in the translation and they seem to work well.

I am supporting this class library.  Because of its simplicity
and my organization of the projects, I feel that it would be
useful to many people struggling with object oriented and
Macintosh programming.

I am submitting my implementation to sumex/info-mac archive
as TCelmC++.hqx.  I'd post it on Compuserve and America
On-Line if I had an account on these services.  Feel free
to distribute my package for me.

Mark Gross
[e-mail]

[saved as: /mac/think-c/examples/elements.hqx; 208K]










Path: ucivax!gateway
From: [e-mail] (Jamie McCarthy)
Subject: CPrinter with no printer chosen
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 32
Date: 2 Aug 91 06:55:44 GMT

The code in CPrinter::IPrinter() reads, in part:

PrOpen();
if (!PrError()) {
    /* set up macTPrint and default stuff */
}
PrClose();

Now, I don't know much of anything about printer drivers.  (Forgive me,
but that's part of why I like OOP--I don't have to worry about it now, I
can wait 'til later to figure it out.)  But I do know that if you
haven't chosen a printer, for example if you've spent three days
restoring a crashed hard disk and haven't gotten around to
opening up the Chooser yet (argh!), macTPrint stays NULL, and the
following lines in CDocument::IDocument() choke:

if (printable) {
        itsPrinter = new(CPrinter);
    itsPrinter->IPrinter(this, NULL);
    macTPrint = itsPrinter->GetPrintRecord();
    pageWidth = (**macTPrint).prInfo.rPage.right;
}

It dies, of course, on the dereferencing of macTPrint.

Seems to me that a little error-checking, most likely in CDocument, is
in order.  Or am I doing something wrong?
--
 Jamie McCarthy                    [e-mail]
 Disclaimer:  it's my responsibility iff they're my words.
 You killed a little dwarf. The body vanishes in a cloud of
 greasy black smoke.










Path: ucivax!gateway
From: infoserv!apple!well![e-mail] (John Draper)
Subject: Re:  QuickDraw32 bit
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 2 Aug 91 17:08:23 GMT


>GetGWorldPixMap?  It's not in my header files either.  What is it supposed
>to do?  I've got a GetPixBaseAddr:
>pascal Ptr GetPixBaseAddr (PixMapHandle pm)

It's supposed to return the BaseAddr of a GWorld.











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: CPrinter with no printer chosen
Message-ID: <[e-mail]>
In-Reply-To: Jamie McCarthy's message of 2 Aug 91 06:55:44 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 30
Date: 2 Aug 91 20:24:37 GMT

From: Jamie McCarthy <[e-mail]>
   The code in CPrinter::IPrinter() reads, in part:

   PrOpen();
   if (!PrError()) {
       /* set up macTPrint and default stuff */
   }
   PrClose();

   [...] if you haven't chosen a printer, for example if you've spent
   three days restoring a crashed hard disk and haven't gotten around to
   opening up the Chooser yet (argh!), macTPrint stays NULL, and the
   following lines in CDocument::IDocument() choke:

   if (printable) {
       itsPrinter = new(CPrinter);
       itsPrinter->IPrinter(this, NULL);
       macTPrint = itsPrinter->GetPrintRecord();
       pageWidth = (**macTPrint).prInfo.rPage.right;
   }

   It dies, of course, on the dereferencing of macTPrint.

   Seems to me that a little error-checking, most likely in CDocument, is
   in order.  Or am I doing something wrong?

This is a bug in the TCL, and it will be fixed in the next major
release of THINK C.

    -phil










Path: ucivax!gateway
From: [e-mail] ("Matthew E. Moses")
Subject: Writing from ThinkC to an Excel spreadsheet format.
Message-ID: <[e-mail]>
X-Mailer: Elm [version 2.1 PL0]
Newsgroups: fa.think-c
Lines: 11
Date: 3 Aug 91 19:18:35 GMT

Does anyone have any experience or pointers on how to write to a file in
ThinkC in the Excel spreadsheet format?  I need to write some calculation
data into a form readable be Excel.  Any hints or tips will be appreciated.
Please send them to my mail rather than over this list and I will summarize
if their is any interest. Thanks.


**************************************************************************
*   Matthew E. Moses   *   [e-mail]   *                   *
*                      * [e-mail] *                   *
**************************************************************************










Path: ucivax!gateway
From: [e-mail] (JON)
Subject: THINK C 5.0
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 13
Date: 6 Aug 91 03:36:52 GMT
X-Envelope-to: [e-mail]

Hi!  I am on the market to buy Think C, and I was just about to buy it when I
looked in the MacUser that I received today, in the MacWarehouse add they are
advertising version 5.0 for $209.  I called them and they told me that the
release date was Aug 7th.
Does anyone know anything about this upcoming release???  I heard a couple of
things about integrating some C++ into it on Compuserve, and the add talks
about taking full advantage of new System 7.0 capabilities.
Lastly, does anyone know of any type of educational discount one can get on
THINK C from Symantec itself that would beat this price???
        Thanks in advance for replies"!!!
        -Jon Christiansen
        [e-mail]
        [e-mail]










Path: ucivax!gateway
From: [e-mail] ("John Champion(907")
Subject: Compactor compression algorithm
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 6 Aug 91 23:35:36 GMT

Does anyone know where I might find some source code that uses the same
algorithm for compression/decompression that Compactor uses?  This one
seems to offer the best compression ratio, as well as a speed advantage.
I have a program that uses large input files, and these files must be
passed over a network.  The program must be able to compress/decompress
the files internally, so unfortunately, I cannot just use compactor itself.
Please respond via email, and I will summarize.  Thanks in advance...
       -John Champion










Path: ucivax!gateway
From: [e-mail] (Martin Minow 07-Aug-1991 0743)
Subject: Think C 5.0 announced
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 36
Date: 7 Aug 91 11:42:32 GMT

The Think folk are all at MacWorld, so I'll post a quick note.

Think 5.0 (and Think Pascal 4.0 (?)) were released on Monday.  Think C
is Ansi complient, supports System 7, is 32-bit clean, etc. etc.
The compiler has an optional code optimizer.  You can list the output
of the pre-processor and the code generator.  (The latter isn't quite
the help you might wish, as the assembler listing lacks the hex values
and variable locations are all "000000(a5)" or some-such.)

The Think folk decided to make the compiler Ansi-complient rather than
C++ complient. Missing C++ features include operator overloading, inline
functions in methods, multiple inheritence, probably others. On the other
hand, it does support // comments, public, private and protected instance
variables and functions (but not friends), and the "new" and "delete" object
operators, as well as Method (constructor) and ~Method (desctructor).

There are a lot of little improvements: the debugger remembers breakpoints,
expressions, and window locations, for example.  You can also write
MPW-style #pragma parameter inlines.

TCL has had extensive changes, including a bazillion new classes, a very
nice browser, 32-bit visual coordinates, and core Apple Event support.
There's also an exception handler.  The bad news is that a "hello world"
project is about 2 Mb large.  Unfortunately, it takes a moderate amount
of work to upgrade TCL applications (mostly to handle the 32-bit graphics
environment).  Upgrading to use all the new stuff -- and there is a huge
amount of it -- will require more work.  For example, if you play fast
and loose with superclass variables (rather than calling the superclass
access methods), you'll have to clean up your act.

As I recall, upgrades are free if you bought Think C after June 1, $89 if
earlier.

Martin Minow
[e-mail]











Path: ucivax!gateway
From: [e-mail] (Ephraim Vishniac)
Subject: Re: Think C 5.0 announced
Message-ID: <[e-mail]>
In-Reply-To: Your message of "07 Aug 91 11:42:32 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 7 Aug 91 13:55:50 GMT


   From: Martin Minow 07-Aug-1991 0743 <[e-mail]>
   Date: 7 Aug 91 11:42:32 GMT

   The Think folk are all at MacWorld, so I'll post a quick note.

   Think 5.0 (and Think Pascal 4.0 (?)) were released on Monday.  Think C
   is <lots of good stuff>

I talked to Phil Shapiro at the show, and he confirmed that my two pet
peeves were fixed in 5.0:

1. If you supply a full prototype for a pointer to function, the
compiler actually uses the prototype. This was obscure, but a real
killer if it bit you.

2. When argument types mismatch, the compiler tells you which argument
it's talking about. It doesn't tell you the actual and expected types,
but you can't win them all.











Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: Communication Toolbox Glue
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 26
Date: 7 Aug 91 14:46:31 GMT
X-Phone: [phone] x115


Date: Mon, 5 Aug 91 11:51:12 edt
From: Phil Shapiro <[e-mail]>
Subject: CTBGlue-C.cpt.hqx

I'm submitting a converted version of the Communications Toolbox Glue
for THINK C 4.0.x for the think-c archives.  This is the "official"
conversion, and it's recommended if you want to take advantage of the
new CTB calls and you're not using the interim System 7.0 headers.
This archive doesn't contain any documentation about how to use the
CTB, and it doesn't include the CTB INIT itself or any Tools.  For
more info about the CTB, contact APDA.

I thought that these interfaces had already been posted to the think-c
archives, but I couldn't find them there.  Disregard this is you've
already got these files.

This is a binhex'd Compact Pro archive.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]

[saved as: /mac/think-c/symantec/ctbglue.hqx; 28K]










Path: ucivax!gateway
From: [e-mail] (Erik Reuter)
Subject: Re: Think C 5.0 announced
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 7 Aug 91 18:01:42 GMT

     In case you are interested about the upgrade to 5.0, I called Symantec
Customer Service ( 1-800-441-7234 ) and after a long wait, spoke to someone
who took my upgrade order for 5.0. She said they were taking "manual
orders" which means that she writes it down, and later (when they get the
database program ready to handle the upgrade?) they will enter it into the
computer. She didn't know when it would ship, but said it would be in a few
weeks. It cost $89 + tax + $5 shipping. Incidentally, be prepared for a 10
minute wait on the line until you are helped.

     If anyone knows any more about when things will ship, please let us
know.


  Erik Reuter  [e-mail]











Path: ucivax!gateway
From: [e-mail]
Subject: Think C 5.0 announced
Message-ID: <9108072117.AA11489@husc10>
In-Reply-To: Erik Reuter's message of 7 Aug 91 18:01:42 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 7 Aug 91 21:18:32 GMT


The customer service line is very busy processing upgrades for some of
Symantec's DOS products.  There is a line for THINK C upgrades it is
1-800-228-4122 x811.  I called them and got through very quickly.

--Erik










Path: ucivax!gateway
From: [e-mail] ("Edward V. Wright")
Subject: Re: Think C 5.0 announced
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 7 Aug 91 21:18:47 GMT

I was told to allow "two to four weeks" for delivery.  I was also told
that the price would be $69 + tax + shipping (maybe a discount because
I ordered C and Pascal both?).










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: THINK C and THINK Pascal Press Release
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 103
Date: 7 Aug 91 22:27:12 GMT

SYMANTEC ANNOUNCES NEW VERSION OF TOP-RATED MACINTOSH
DEVELOPMENT ENVIRONMENTS

Cupertino, CA -- August 6, 1991 -- Enabling programmers to
fully utilize the capabilities and features of System 7,
Symantec Corporation (NASDAQ: SYMC) today announced THINK C
version 5.0 and THINK Pascal version 4.0, enhanced versions
of its popular development environments.

"As the market leader in Macintosh development environments,
Symantec provides programmers with strong tools that fully
exploit state-of-the-art technology," said Gordon E.
Eubanks, Jr., president and chief executive officer.  "With
support for Apple's System 7 and enhanced object-oriented
programming capabilites, THINK C version 5.- and THINK
Pascal version 4.0 are the ideal tools for Macintosh
developers."

New features in THINK C version 5.0

The multi-pass, optimizing compiler and code generator in
THINK C version 5.0 have been completely rewritten to
produce the most compact, efficient C code on the Macintosh.
An optional global optimizer further reduces code size and
execution time.  THINK C is now 100 percent ANSI conformant;
ANSI conforming applications written in THINK C are portable
to other platforms.

With THINK C programmers can use the latest System 7
technologies.  THINK C runs under System 7 in both 24- and
32-bit modes, with or without virtual memory.

New object-oriented programming (OOP) tools include a class
browser that provides a graphical view of a program's
classes and makes navigating and editing OOP code easier.
The THINK Class Library provides the building blocks for a
standard Macintosh user interface such as windows, menus and
controls.  THINK Class Library enhancements include new
classes for dialogs, multi-window documents and System 7
support.

Markers have been added to the THINK C editor for moving
more easily through large source files.  The integrated
source-level debugger remembers breakpoints and data
displays between sessions, enabling programmers to keep
their place in the program.  Other new features include
Disassemble and Preprocess commands that allow programmers
to view their code in different forms, and the ability to
generate link maps during the compile cycle.  An increase in
the jump table limit now allows THINK C to support large
projects.

New features in THINK Pascal version 4.0

The THINK Pascal compiler generates the smallest and fastest
Pascal code on the Macintosh.  Like THINK C, all of the
tools in the THINK Pascal environment are completely
integrated for fast turnaround.  THINK Pascal supports
System 7, allowing developers to write programs that use
System 7 technologies.  THINK Pascal runs under System 7 in
both 24- and 32-bit modes, with or without virtual memory
and supports the required set of Apple events.

The new Instant Project feature lets programmers create a
project with a single command, automatically opening the
project document, loading the libraries and opening a source
file in the editor.  There is also support for larger
projects, including Far Code and multiple segments in any
project type, allowing programmers to develop very large
applications more quickly.

THINK Pascal includes a Pascal version of the enhanced THINK
Class Library to provide Macintosh programmers with
additional object-oriented programming capabilites.  "Apple
is committed to the success of our third-party developers,"
said Roger Heinen, vice president of Macintosh Software
Architecture at Apple Computer, Inc.  "We are extremely
pleased to see the the two popular development environments
for the Macintosh, THINK C and THINK Pascal, now offer
complete System 7 support.  These products really underscore
Symantec's committment to the thousands of Macintosh
programmers who are eager to take full advantage of system 7
to build new and exciting Macintosh applications."

THINK C version 5.0 requires a Macintosh Plus or higher with
a minimum or 2 MB or RAM.  The debugger requires 2 MB of RAM
and MultiFinder.  System Software version 6.0 or higher is
required.  A hard disk is recommended and required for the
THINK Class Library.  The suggested retail price is $299.
Registered users can upgrade for $89.

THINK Pascal version 4.0 requires a Macintosh Plus or higher
with a minimum of 1 MB or RAM (2 MB recommended); 4 MB
recommended for use with the THINK Class Library or Apple's
MacApp.  System Software version 6.0 or later is required.
A hard disk is recommended and required for the THINK Class
Library or MacApp.  The suggested retail price is $249.
Registered users can upgrade for $69.

THINK C version 5.0 and THINK Pascal version 4.0 are
available now through Symantec's network of distributors and
resellers.  For further information on either product,
customers can call 800-441-7234 or 408-252-3570.










Path: ucivax!gateway
From: [e-mail]
Subject: Problems with UpdateGWorld...?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 37
Date: 7 Aug 91 23:02:55 GMT


I need to frequently change the size of my GWorld.  So, I'm assuming I
can (and should) use UpdateGWorld() to do it.  So I send my GWorldPtr
to UpdateGWorld, with the new boundsRect, like so:

/* I'm calling this from within a Think Class Library object. */
/* macWorld is an instance variable for the object, declared as */
/* a GWorldPtr, and initialized thus: */
/*     theErr = NewGWorld( &macWorld, depth, &bounds, NIL, NIL, 0L ); */
/* pixelDepth is also an instance variable, and is set at the time of */
/* the above call.  theBounds is passed to the routine as a Rect *, */
/* and represents the new boundsRect for the offscreen world (always */
/* a larger Rect than the old boundsRect) */

MoveHHi( (Handle) this );
HLock( (Handle) this );
result = UpdateGWorld( &macWorld, pixelDepth, theBounds, NIL, NIL, clipPix );
HUnlock( (Handle) this );


It seems to work, i.e. macWorld->portRect and
(*macWorld->portPixMap)->boundsRect are equivalent to theBounds after the
call, and 'result' is zero.  The problem is that I seem to be losing the
contents of my PixMap in the process.  I.e. the previous image becomes
garbage.  Is this supposed to happen?  I got the distinct impression from
IM-VI that it isn't.  What could I be doing wrong?  How can I avoid the
problem if not solve it (somehow increase the bounds of my PixMap without
calling UpdateGWorld)?

I've been working on this for the last 24 hours or so - any and all help
will be rewarded with my deepest gratitude. :)

Mike.
_____________________________________________________________________________
Michael A. Kelly                                   America Online: Michael792
[e-mail] or [e-mail]              Compu$erve: 73567,1651
_____________________________________________________________________________










Path: ucivax!gateway
From: [e-mail]
Subject: Problems with UpdateGWorld...?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 33
Date: 8 Aug 91 01:27:15 GMT


I need to frequently change the size of my GWorld.  So, I'm assuming I
can (and should) use UpdateGWorld() to do it.  So I send my GWorldPtr
to UpdateGWorld, with the new boundsRect, like so:

/* I'm calling this from within a Think Class Library object. */
/* macWorld is an instance variable for the object, declared as */
/* a GWorldPtr, and initialized thus: */
/*     theErr = NewGWorld( &macWorld, depth, &bounds, NIL, NIL, 0L ); */
/* pixelDepth is also an instance variable, and is set at the time of */
/* the above call.  theBounds is passed to the routine as a Rect *, */
/* and represents the new boundsRect for the offscreen world (always */
/* a larger Rect than the old boundsRect) */

MoveHHi( (Handle) this );
HLock( (Handle) this );
result = UpdateGWorld( &macWorld, pixelDepth, theBounds, NIL, NIL, clipPix );
HUnlock( (Handle) this );


It seems to work, i.e. macWorld->portRect and
(*macWorld->portPixMap)->boundsRect are equivalent to theBounds after the
call, and 'result' is zero.  The problem is that I seem to be losing the
contents of my PixMap in the process.  I.e. the previous image becomes
garbage.  Is this supposed to happen?  I got the distinct impression from
IM-VI that it isn't.  What could I be doing wrong?  How can I avoid the
problem if not solve it (somehow increase the bounds of my PixMap without
calling UpdateGWorld)?

I've been working on this for the last 24 hours or so - any and all help
will be rewarded with my deepest gratitude. :)

Mike.










Path: ucivax!gateway
From: [e-mail] (Chris McNeil)
Subject: fortune database
Message-ID: <[e-mail]>
X-Mailer: QuickMail/SMTP interface.
Newsgroups: fa.think-c
Lines: 6
Date: 8 Aug 91 15:26:35 GMT

I need a fortune database ( something like fortune.dat on SUN's) but in ascii
form  for a cookie server for MAC's that I'm writing. Does anyone know where to
get one ?

Chris McNeil
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Jamie McCarthy)
Subject: Sneaky class-changing
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 55
Date: 9 Aug 91 18:28:57 GMT

Let me explain the situation first, and then the two ways I'm thinking
of approaching it.  I'm looking for feedback about any of this; either
email or net discussion is probably fine.

The situation is:  I've got a pane in a window whose display and
reactions to events needs to change--in other words, which needs to
change classes.  When one of these transitions occurs, I need to tell
it to do some transitory stuff like changing palettes, get it to display
something, make _some_kind_ of changeover, and suddenly have a new class
occupying the same space in the window, with _no_ update event pending
for that space.  (The new class will start off displaying exactly the
same thing that the old class departed with.)

Approach One:  dink with the object.  Both these CPane subclasses are
about four levels down from CPane, and are a lot more similar than they
are different.  Can I physically change the object type, eg:

CPaneSubclass1 *oldPane;
CPaneSubclass2 *newPane;
oldPane->doPreChangeoverStuff();
newPane = oldPane;
SetHandleSize((Handle) newPane, sizeof(CPaneSubclass2));
bless(newPane, CPaneSubclass2);
newPane->doPostChangeoverStuff(); /* including init'ing the new class
variables, which contain trash--but those vars common to both classes
are still valid */

I don't see any reason why this wouldn't work, but then again there may
be evil things lurking in the hearts of THINK objects.  Presumably, if
changing the handle size works, so would copying the handle with
HandAndHand and disposing of the original with DisposHandle instead of
oldPane->Dispose().

Approach Two:  dink with the invalRgn.  This would mean creating a
method like validateMyFrame() for all my CPane subclasses; the code
would look like:

CPaneSubclass1 *oldPane;
CPaneSubclass2 *newPane;
oldPane->doPreChangeoverStuff();
oldPane->Dispose(); /* invalidates the pane's frame */
newPane = new(CPaneSubclass2);
newPane->ICPaneSubclass2(...);
newPane->validateMyFrame(); /* re-validates the same area, before any
update events get called */

Is this plausible as well?

Has anyone does anything like this before?  If not, which approach looks
on the face of things more reasonable?
--
 Jamie McCarthy                    [e-mail]
 Disclaimer:  it's my responsibility iff they're my words.
 The bear eagerly wolfs down your food, after which he seems to calm
 down considerably and even becomes rather friendly.










Path: ucivax!gateway
From: [e-mail] ("Povl H. Pedersen")
Subject: Class library and MPW C++
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-Vms-To: IN::"[e-mail]"
Lines: 13
Date: 10 Aug 91 09:01:34 GMT
X-Envelope-To: [e-mail]


Is there anybody out there who has tried to compile the class library
in MPW C++, and thus get a real object oriented class out of it.
C++ is still far better than ANSI C, that is why I had to switch to MPW
quite recently, and I like it. It is much slower to compile though,
but the complete MPW environment is much better.

How much has the class library been enhanced in the new 5.0 ? And is
these portable into C++ without too much trouble ? I am very interested
in this, but I think I will upgrade anyway.

Povl H. Pedersen
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Kenneth B. Kirksey")
Subject: 4.0.5 / Sys 7 Debugger Problem
Full-Name: Kenneth B. Kirksey
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 11 Aug 91 02:36:59 GMT


    I recently upgraded to System 7 and a couple of days after that I updated
Think C and the Think C Debugger to 4.0.5.  I didn't use my old version of
Think C (4.0.4?) under Sys 7 so I don't know if that version would not have had
this problem.

    What this problem is:  When I chose "Use Debugger" and run my program (which
is a simple program that does little more that output to a console window)  the
debugger starts up and immediately starts running.  It doesn't show any source
in the source window, and doesn't let me set any data values to watch.  It just
goes.  And when the program crashes, it just locks up the debugger and
doesn't display any info.  Has anyone else had this problem, or have any
idea what might be causing it?

                                 Ken

[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Kenneth B. Kirksey")
Subject: Debugger Problem
Full-Name: Kenneth B. Kirksey
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 11 Aug 91 03:02:53 GMT


    I recently upgraded to System 7 and a couple of days after that I updated
Think C and the Think C Debugger to 4.0.5.  I didn't use my old version of
Think C (4.0.4?) under Sys 7 so I don't know if that version would not have had
this problem.

    What this problem is:  When I chose "Use Debugger" and run my program (which
is a simple program that does little more that output to a console window)  the
debugger starts up and immediately starts running.  It doesn't show any source
in the source window, and doesn't let me set any data values to watch.  It just
goes.  And when the program crashes, it just locks up the debugger and
doesn't display any info.  Has anyone else had this problem, or have any
idea what might be causing it?

                                 Ken










Path: ucivax!gateway
From: infoserv!apple!well![e-mail] ("Brian M. Hamlin")
Subject: Re:  Problems with UpdateGWorld...?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 11 Aug 91 17:07:27 GMT

  The problem is that the gWorldFlags must be set to either
clipPix or stretchPix. 0 results in no more bits!
  This is not immediately obvious from the docs...

  -Brian










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Debugger Problem
Message-ID: <[e-mail]>
In-Reply-To: "Kenneth B. Kirksey"'s message of 11 Aug 91 03:02:53 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 30
Date: 11 Aug 91 22:57:40 GMT

   I recently upgraded to System 7 and a couple of days after that I
   updated Think C and the Think C Debugger to 4.0.5.  I didn't use my
   old version of Think C (4.0.4?) under Sys 7 so I don't know if that
   version would not have had this problem.

Don't use versions 4.0.3 or 4.0.4; they were beta releases that were
made available to developers that used beta versions of Apple's System
7. You should use THINK C 4.0.5 (or 5.0) with System 7.

   What this problem is: When I chose "Use Debugger" and run my
   program (which is a simple program that does little more that
   output to a console window) the debugger starts up and immediately
   starts running.  It doesn't show any source in the source window,
   and doesn't let me set any data values to watch.  It just goes.
   And when the program crashes, it just locks up the debugger and
   doesn't display any info.  Has anyone else had this problem, or
   have any idea what might be causing it?

This is usually a sign of running VM under System 7.  Apple's VM
scheme (unlike Connectix's Virtual) uses a different format for the
stack during exception handling than was previously used.  This breaks
THINK C and THINK Pascal's debugger code, and will cause them to crash
or be ineffective.  Don't use Apple's VM with the THINK C 4.0.x
Debugger, and it should work correctly.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Rotating PICTs
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 12 Aug 91 16:15:15 GMT

I think the subject says it all. How can I rotate PICT images by 90 degrees
like MacDraw does. I know of two approaches in theory (parse the pict, or
customize quickdraw low-level drawing routines) but I need real Code. Can
anybody help with this, please. Any pointers and/or code fragments will be
very appreciated.


Carlos Bazzarella.
University of Waterloo.
[e-mail]











Path: ucivax!gateway
From: [e-mail]
Subject: MPW fortran and THINK C 4.0.2
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 12 Aug 91 22:50:05 GMT

Does anyone out there have any experience linking MPW fortran code with
THINK C?  I'm using Language Systems Fortran 2.1.  I've tried converting
what appear to be object files to THINK C libraries using oConv without
success (wrong object file format).  I'm also quite concerned about
parameter passing and function calling, since THINK C doesn't have a
fortran keyword.

Thanks for your help,

Steve Fry











Path: ucivax!gateway
From: [e-mail]
Subject: Re: Problems with UpdateGWorld...?  *** Solution ***
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 42
Date: 13 Aug 91 01:54:35 GMT


Several people responded to my desperate plea for help regarding my
ill-fated call to UpdateGWorld, saying that they, too, had had problems.
One person even went so far as to say the problem was fixed in System 7.
I finally called up Bruce Leak to see if there was really anything wrong
with UpdateGWorld, and sure enough, his answer was "Use System 7".  (I was
using an fx with System 6.0.7.)  So I switched to System 7 (finally) and
my program stopped crashing.  The PixMap was still getting trashed during
each call to UpdateGWorld, but the new PixMap was valid (whereas before it
wasn't).  So I would end up with garbage everywhere except for what I drew
after the call to UpdateGWorld.  According to every bit of documentation
I had, I was calling it correctly:

flags = UpdateGWorld( &myWorld, oldDepth, &newBounds, nil, nil, clipPix );

...but flags was coming up 0x20100000 (which is stretchPix + reallocPix).  I
checked the value of clipPix in the Think C Debugger, and it was 0.  "Hmmm..."
I thought.  So I changed the call to:

flags = UpdateGWorld( &myWorld, oldDepth, &newBounds,
            nil, nil, 1L << clipPixBit );
                      ^^^^^^^^^^^^^^^^
...and it worked!!  flags was 0x10100000, which is clipPix + reallocPix
(so doesn't that mean that my image was discarded?), and my image remained
intact.

But why is clipPix zero?  It is defined in Quickdraw32Bit.h as

#define clipPix  (1L << clipPixBit)


I'm confused.... but happily confused....


Thanks again to all who responded,


Mike.
_____________________________________________________________________________
Michael A. Kelly                                   America Online: Michael792
[e-mail] or [e-mail]              Compu$erve: 73567,1651
_____________________________________________________________________________










Path: ucivax!gateway
From: [e-mail] ("David R. Stampf")
Subject: Random
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 41
Date: 13 Aug 91 02:31:34 GMT


I've been trying to use Random (IM-1) and randSeed with some disappointing
results. The program is:

/*
 *    random seems to be stuck!
 */

main()
{
    int i;

    printf("\n");
    GetDateTime(&randSeed);
    printf("%lx\n",randSeed);

    i = Random();
    printf("%d\n",i);

    /* randSeed should have changed. */

    printf("%lx\n",randSeed);
}


---

    I set the randSeed from GetDateTime and print it out. I then ask for
one random number, then print out randSeed again. When the program runs
(under think-c with or without the debugger or as an application) I *always*
get the same random number, and randSeed *never* changes. A typical output
looks like:

a4ccb586
16807
a4ccb586


Any ideas about what gives here?

    < dave










Path: ucivax!gateway
From: [e-mail] ("Mark Nutter, Apple Support")
Subject: Re: Random seems to be stuck
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: NETMAIL%"[e-mail]"
Lines: 18
Date: 13 Aug 91 12:35:59 GMT
X-Envelope-to: [e-mail]
X-Organization: Indiana University of Pennsylvania

I ran afoul of the same quirk a while back, and eventually came to the
conclusion that it was because I was mixing <stdio> calls with standard Mac
Toolbox calls.  Think C <stdio> seems to set up its own grafport, with its own
randSeed, separate and apart from the one you are setting.  random() seems to
access the <stdio> randSeed you are NOT setting.

My solution was to call all the InitXxxx... calls like InitGraf(&thePort),
InitFonts, etc., before the call to printf("\n"); (at least I THINK it was
before printf();).  This seems to synchronize the randSeeds.

-----------------------------------------------------------------------------
Mark Nutter                                                      MANUTTER@IUP
Apple Support Manager
Indiana University of Pennsylvania
G-4 Stright Hall, IUP
Indiana, PA 15705
"You can lead a horse to water, but you can't look in his mouth." - Archie B.
=============================================================================










Path: ucivax!gateway
From: [e-mail] (Ephraim Vishniac)
Subject: Assembler stronger in 5.0?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 13 Aug 91 12:53:33 GMT


Something I forgot to ask Phil Shapiro at the show:

Through Think C 4.0.5, the in-line assembler didn't recognize the
difference of two constant addresses as a constant. This made it
difficult to build some kinds of tables.

Is this fixed in 5.0? If it is, then I'll be the first to say that
Think C is the nicest assembler environment for the Mac.











Path: ucivax!gateway
From: [e-mail] ("Matthew T. Russotto")
Subject: Re:  Random
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 2
Date: 13 Aug 91 13:34:36 GMT

When you initialize the quickdraw globals with the console library, the standard
QD globals (randseed, etc) are not the used by Quickdraw.










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Assembler stronger in 5.0?
Message-ID: <[e-mail]>
In-Reply-To: Ephraim Vishniac's message of 13 Aug 91 12:53:33 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 13 Aug 91 15:30:04 GMT

   Through Think C 4.0.5, the in-line assembler didn't recognize the
   difference of two constant addresses as a constant. This made it
   difficult to build some kinds of tables.

   Is this fixed in 5.0? If it is, then I'll be the first to say that
   Think C is the nicest assembler environment for the Mac.

Sorry, but this feature didn't make it into C 5.0.  The inline
assembler was rewritten for C 5.0, but it doesn't support any new
features that weren't present in C 4.0.  (I'll add it to to our
requests list for the next major release.)

Do we still qualify for 2nd nicest :-) ?

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Kirk Swenson)
Subject: Assembler in 5.0
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 13 Aug 91 17:32:23 GMT

Regarding the use of the difference of two constant addresses as a constant
in the inline assembler, Phil Shapiro writes:

>Sorry, but this feature didn't make it into C 5.0.  The inline
>assembler was rewritten for C 5.0, but it doesn't support any new
>features that weren't present in C 4.0.  (I'll add it to to our
>requests list for the next major release.)

I wouldn't think that this would be such a difficult feature to add.
Do we really have to wait for the next MAJOR release?  That could be
quite a while, and I've been missing this feature as well.  I'm getting
tired of writing code to subtract two addresses rather than having the
assembler take care of it.

Kirk Swenson
[e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: System 7.0 Headers and LaunchApplication
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 13 Aug 91 20:49:05 GMT

I am trying to use the new LaunchApplication routine in System 7.0 using
the new System 7.0 headers and libraries from THINK C.  Unfortunately, I
keep getting the link error "undefined:  LaunchApplication".  I have
#included <Processes.h> in my source code and the new MacTraps library in
my project file.  Still, no luck.  Incidentally, I can call
LaunchDeskAccessory without any problems.

Is there a problem here with the 7.0 headers and libraries, or am I doing
something wrong?

-------------------------------------
- Richard Beecher ([e-mail]) -
--------------------------------------











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: System 7.0 Headers and LaunchApplication
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 13 Aug 91 20:49:05 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 13 Aug 91 21:48:54 GMT

   I am trying to use the new LaunchApplication routine in System 7.0
   using the new System 7.0 headers and libraries from THINK C.
   Unfortunately, I keep getting the link error "undefined:
   LaunchApplication".  I have #included <Processes.h> in my source
   code and the new MacTraps library in my project file.  Still, no
   luck.  Incidentally, I can call LaunchDeskAccessory without any
   problems.

   Is there a problem here with the 7.0 headers and libraries, or am I
   doing something wrong?

The glue for LaunchApplication was left out of the 7.0 headers by
accident.  Here's the inline definition for LaunchApplicaion:

pascal OSErr LaunchApplication(const LaunchParamBlockRec *LaunchParams)
    = {0x205F,0xA9F2,0x3E80};

If you don't set the option launchContinue in the field
launchControlFlags (IM VI, 29-15), i.e. your application will quit,
then you must call the routine _exiting(1) before you call
LaunchApplication.  If you don't do this, strange things will happen.

See the implementation of the unix library routine exec(), in the file
unixmisc.c for an example of this.

    -phil










Path: ucivax!gateway
From: [e-mail] (Craig)
Subject: getting the subclassed object
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 14 Aug 91 18:24:03 GMT

Suppose I have a Shape class.  Furthermore suppose, there are two subclasses
of Shape, Square and Circle.  Now if I create a list of Shape objects, is
there any way to get the subclassed object.  What I really want to do
is say TheShape->Draw() and have it draw a Square or a Circle depending
upon which type of shape we are dealing with.  I think what I need is a
virtual declaration.  However, that is not provided in Think 4.0.5.
So I guess my real question would be is there any way around this?  Given
an instance of a Shape is there any way that I can call Circle's Draw() method?

If this is pure jibberish you may safely disregard it.
Craig










Path: ucivax!gateway
From: [e-mail] (Daniel Sears)
Subject: List Manager example wanted
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 14 Aug 91 20:59:51 GMT

Hello,

Does anyone have any Think C code for using the List Manager in a dialog box?
Right now I am using a bunch of radio buttons that is getting too long and
I would like to change this to use the List Manager.  Sample code would be
appreciated.

--Dan ([e-mail])










Path: ucivax!gateway
From: [e-mail]
Subject: [NEWS] Symantec += Zortech
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 35
Date: 14 Aug 91 22:41:01 GMT

----------
Business Wire
Tuesday, 13 August 1991
(Reposted without permission)
----------

SYMANTEC CORP. ANNOUNCES ACQUISITION OF ZORTECH ...

CUPERTINO, CA (AUG. 13) BUSINESS WIRE - Symantec Corp. (NASDAQ:SYMC)
announced Tuesday that it has acquired Zortech Inc., the Woburn, Mass-based
developer of cross-platform C++ compilers.
   Symantec is currently the leading independent developer of Macintosh
languages  with award winning products including Think C and Think Pascal.
   Zortech is an innovator in the rapidly emerging market segment for C++
development environments, which it spearheaded in 1988 with the release of the
first native code C++ compiler for DOS.
   Today, Zortech has industrial-strength C++ compilers for DOS, Windows,
OS/2, UNIX and the Macintosh.  This acquisition will expedite Symantec's
entrance into the emerging market for industrial-strength, cross-platform C++
development environments for the corporate developer.
   This acquisition is a pooling of interest in which Symantec will exchange
238,095 shares of its common outstanding stock for the current outstanding
shares of Zortech stock.
   Zortech has offices in Massachusetts and London.  The Zortech staff will
report to Julie Bingham, currently director of Symantec's language and
integrated products group, located in Bedford, Mass.
   Symantec Corp., develops, markets and supports a complete line of
application and system software products for IBM personal computers and
compatibles, and Apple Macintosh computers.
   Founded in 1982, the company has offices in the United States, Canada,
Australia and Europe.  Information on the company and products can be obtained
by calling 408/253-9600.

----------











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: getting the subclassed object's method
Message-ID: <[e-mail]>
In-Reply-To: Craig's message of 14 Aug 91 18:24:03 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 14 Aug 91 23:48:00 GMT

   Suppose I have a Shape class.  Furthermore suppose, there are two
   subclasses of Shape, Square and Circle.  Now if I create a list of
   Shape objects, is there any way to get the subclassed object.  What
   I really want to do is say TheShape->Draw() and have it draw a
   Square or a Circle depending upon which type of shape we are
   dealing with.  I think what I need is a virtual declaration.
   However, that is not provided in Think 4.0.5.  So I guess my real
   question would be is there any way around this?  Given an instance
   of a Shape is there any way that I can call Circle's Draw() method?

In THINK C 4.0, all methods of an object are implicitly virtual.  So,
the correct function is called when the object's method is dispatched.
This is traditionally called "object polymorphism".

In THINK C 5.0, there's a compiler switch that lets you toggle between
all methods being implicitly virtual, and requiring the virtual
keyword.  This way, it's easy to port over C 4.0 OOP programs.

Both versions produce direct calls for virtual monomorphic methods, so
you don't lose any performance for methods that are never overridden.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: C++, here we come!!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 15 Aug 91 03:45:21 GMT


could it take more than 6 months to come up with a "port"
of Zortech's compiler??  i mean, it's just a compiler
compiler (or something like that...),  so making adjustments
to fit into think's quirks should be moderate, if not
minimal.

or, so sayeth one who knoweth not.  but please, please!
let it come swiftly!!

:jeff bellsey











Path: ucivax!gateway
From: van-bc!vital![e-mail] (Brad Kollmyer)
Subject: Re: Think C 5.0 announced
Message-ID: <[e-mail]>
X-Mailer: uAccess - Mac Release: 1.5
Newsgroups: fa.think-c
Reply-To: Brad Kollmyer <vital![e-mail]>
Organization: Vital Consulting
Lines: 9
Date: 15 Aug 91 05:31:34 GMT


In Regards to your letter <[e-mail]>:
|I was told to allow "two to four weeks" for delivery.  I was also told

I placed my order last week, and received my update just yesterday.
I was quoted a four to six week delivery time.

Brad.











Path: ucivax!gateway
From: [e-mail] (David Sugar)
Subject: Questions??
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 32
Date: 15 Aug 91 23:19:51 GMT


  First off, how do I get on the mailing list to get this group??  I was
looking around on the FTP site when I noticed the archives and reading
through one of them I decided that this group would be great for me to get
on to, but can't figure out how.

  Secondly, I have a C related question.  I am using Think C, and I am trying
to read and write from a resource that is in the application that I am working
on.  So, with ResEdit I made a resource called 'test' and I would like to be
able to write an integer to this resource.  So, I have variables, data is an
int, data_ptr is a Ptr, and data_handle is a Handle, to make it easy.  Then
I assign data 300 but, when I assign *data_ptr=data; then *data_ptr = 44 now,
that is my biggest problem, because then when I write the data to the
resource with AddResource it saves it as 44, not 300.  I'm very new to
programing in C and on the Mac with the tool box calls and all.  I'm sure
that this is a very simple thing to do.  I eventually want to be able to
write an entire array to a resource, but figured starting out writing integers
and building up to the arry would be the best way to approach the problem,
but that is where I am stuck.

  I would appreciate any suggestions that you can think of, the first one
should be the easist..  Anyway, if you could please send responces directly
to me because I am not, as of this very second, getting the news group sent
to me.  Thanks..

  David Sugar
  [e-mail]
  udsugar@129.25.7.100
  udsugar@129.25.10.1

  Thanks very much..











Path: ucivax!gateway
From: [e-mail] (Steve Greenfield)
Subject: Think C 5.0
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 16 Aug 91 18:15:48 GMT

I purchased Symantec's Think C 4.0 in April 1991 from our University
Bookstore for $80.  As a member of this list I have noticed that the upgrade
to 5.0 has been announced.  I called Symantec about the upgrade and they
told me that it would cost me $89 plus $5 shipping for the upgrade to 5.0.
I can't see paying $14 more for the upgrade than I did for the original
release!

Is there anyway to get a University discount for the upgrade?  If I cannot
get the upgrade to 5.0 due to the price, how do I go about upgrading my
4.0 release to 4.2 or higher release thru the network/ftp?  Where can I
get the upgrade code and does the file you GET have instructions on how
to apply the upgrade?  Can Think C 4.0 run under System 7?

Thanks in advance!!!

Stephen L. Greenfield
Virginia Polytechnic Institute
Blacksburg, Virginia

Bitnet:    FEATS@VTVM1
Internet:  [e-mail]










Path: ucivax!gateway
From: [e-mail] (David Sugar)
Subject: Thanks/stuff
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 16 Aug 91 20:49:32 GMT


  Thanks to everyone who replied to my question, I think that I have figured it
out with our help.  I'll post a follow up when I get it working telling anyone
else with simular problems how it works.

  As for the person wh bought Think C 4.0, I can't remeber your name off hand,
but, with the updaters to Think C 4.0.5, which I'm pretty sure you can ftp
form ics.uci.edu and from sumex it runs fine on System 7.0, that's what I
am running right now.  As for getting Think C 5.0, I think you should try
getting the update through your school, but I don't know if they will give
it to you..

  David Sugar











Path: ucivax!gateway
From: [e-mail]
Subject: Symantec: real customer service
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 17 Aug 91 00:18:25 GMT

Talk about service! Wednesday I called in my order for the TC 5.0
upgrade.  The clerk told me that orders were generally arriving in four
to six weeks, but since I'm in California to expect it in ten days. It
arrived Thursday.  (The yellowjacket nest in my bedroom wall kept me
from posting earlier, but that's another story.)










Path: ucivax!gateway
From: [e-mail]
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 36
Date: 17 Aug 91 02:24:30 GMT


help!

i'm having a very weird problem, the likes of which i haven't
seen before...

after a certain user input error i call gError->PostAlert().
if the user does this a few times in a row, the result is no
longer the correct alert box and its string, but a seemingly
random occurrence, as follows:

       - 90%: no dialog box appears, yet the system acts as
              if one had.  that is, the menus dim, all clicks
              cause a beep, and the "show balloons" indicates
              that windows are inactive because there is a
              dialog box on screen.  yet no new windows have
              appeared.

       - 5%:  an odd-shaped dialog box does appear.  it may
              be either too wide (for example: starting at the
              left edge of the screen and going off way past
              the right edge), or too narrow, or too tall.

       - 5%:  major system error, as in "bad F-line instruction
              in Think C Debugger", with restart the only option.

any clues?  any place i might BEGIN to look for a culprit?  note
that usually i get the dialog box correctly, at least the first
time i cause the user-input error. when i repeat the action,
weirdness only.

thanks,
:jeff bellsey

[e-mail]











Path: ucivax!gateway
From: [e-mail]
Subject: Re: Symantec: real customer service
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 17 Aug 91 02:55:55 GMT

>
>Talk about service! Wednesday I called in my order for the TC 5.0
>upgrade.  The clerk told me that orders were generally arriving in four
>to six weeks, but since I'm in California to expect it in ten days. It
>arrived Thursday.  (The yellowjacket nest in my bedroom wall kept me
>from posting earlier, but that's another story.)

If anyone finds out about educational discounts, PLEASE post it to this
discussion. Although I will be able to USE it for free (the perks of
working for the University), I won't be able to port it home to play with,
and so I'd like to upgrade it (especially for the new manuals - anyone know
if they're any good? Better than the 4.0 ones, I hope; those were reeeaaaly
ugly).

And yellowjackets are NOTHING... I just got home to my apartment from a
nice round of nine-ball, walked into the room and was attacked by an
extremely frightened BAT. Now, no doors and windows were open...........
Hmmm!!



//Dan
The University of Michigan
Computer-Aided Engineering Network
Macintosh Systems Administration











Path: ucivax!gateway
From: paulr@planet8. (Paul Raulerson)
Subject: Symantec Customer Service...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 17 Aug 91 05:35:56 GMT


>
>Talk about service! Wednesday I called in my order for the TC 5.0
>upgrade.  The clerk told me that orders were generally arriving in four
>to six weeks, but since I'm in California to expect it in ten days. It
>arrived Thursday.  (The yellowjacket nest in my bedroom wall kept me
>from posting earlier, but that's another story.)


OTOP, I oredred my upgrade a week ago last Tuesday, paid extra to have it
shipped to reach me within 7 days. It arrived last Tuesday, exactly
one week after ordered, but the upgrade package had no disks in it. (*sigh*)

After waiting for 37.5 minutes on Symantecs 800 line, I got a nice
receptionist who asked me for my name and number. Since it was getting late,
I persisted till Igot a customer service rep, who set it up to get me the disks.
Of course, I even offered to pay *more* to get the dratted things this week.

It is early Saturday morning, and I still ain't got no disks. Seems they could
have at least sent the pesky disks out as 2nd day air. (The upgrade pack with
manuals but no disks came that way... )

Symantec is usually one of the very best at customer service, but I feel
kinda jerked around with this one.  Aw well, they *always* have a rush at
upgrade time. Now, if I ever see my Think-Pascal upgrade. <grin>

-Paul










Path: ucivax!gateway
From: [e-mail]
Subject: Is it safe to increase the FOPEN_MAX limit ??
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 17 Aug 91 22:27:02 GMT
Bcc: [e-mail]

Hi all:

I would like to increase the FOPEN_MAX limit from 15 to 20.  As far as I
can tell there should be no problems.  The only thing that I can see that
is materially affected by a change in FOPEN_MAX is the allocation :-

FILE __file[FOPEN_MAX]                          ( iomisc.c )

The datatype FILE is only 38 bytes, so I can't see that memory concerns
should be a big deal.  The File Manager looks like it dynamic allocates
what it needs ( I can't find a fixed limit for the max files anywhere).

If anyone sees or knows that I'm missing somthing please let me know.

Thanks in advance.

George

_______________________________________________________________________

George Headley                        Office:  [phone]
Technical Support Consultant
Academic Computing Center             Internet: [e-mail]
University of Wisconsin - Madison     Bitnet:   [e-mail]












Path: ucivax!gateway
From: [e-mail] (Daniel Edward Rudman)
Subject: Electronic Formulation Routines - WANTED!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 18 Aug 91 07:36:50 GMT


Does anyone here have a library of electronic/mathematic routines, such as
FFTs, etc.? Also, any routines/algorithms for wire-routing and component
placement would be REALLY helpful, too!

Graphical elements of the above kind are highly desired as well. Anyone with
experience programming this kind of stuff, PLEASE tell me what kind of things
to look out for and what to expect... I'm not going to try to make another
Mentor Graphics, but I'd sure like to have SOMETHING a little more worthy than
Digi-blah... ;)

Thanks..

//Dan
Aspiring Electrical Engineer wannabe










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: Picture Rotation
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 25
Date: 19 Aug 91 00:22:37 GMT
X-Phone: [phone] x115

Date: Wed, 14 Aug 91 07:38:17 EDT
From: "Manuel A. Perez" <[e-mail]>
Subject: Picture Rotation

What follows is some code that will do 90 degree rotation
of a bitmap.  The code was originally written by Bob Denny
in MacTutor.  I typed it in, and made a few minor changes
to make it work with THINK C and the current OS
(unfortunately still 6.0.7).  I am sending it out because
another member asked for such code yesterday.

Good luck,


Manuel A. Perez

Disclaimer: while my email address says that I work for
the goverment, all of the work for this code was done
in my home machine.  So, there is no association whatsoever
between military purposes and the code included below. Also
It should not be taken as representative of the opinion of
my employer, but then how many times have you seen the President
expressing his opinions in C.

[saved as: /mac/think-c/examples/rotation.shar; 7K]










Path: ucivax!gateway
From: [e-mail] (Jamie McCarthy)
Subject: Using Dispose()d objects' methods
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 17
Date: 19 Aug 91 00:47:48 GMT

For reasons I won't go into, my project will be a lot simpler if I can
do something which I think is just this side of dangerous.  I want to
write a method for an object which will call Dispose() for that object,
and then do a few things more before returning, mostly calling other
objects' methods.  I know it's bad to access any of the object's
variables.  I figure I can make copies of them all on the stack (ie
local vars) and keep using the ones I can't do without, though.  I
realize that I need to be sure not to call any methods for the disposed
object, including inherited methods.

Will I crash and burn if I try this?  Or can I scrape by if I'm
careful?
--
 Jamie McCarthy                    [e-mail]
 Disclaimer:  it's my responsibility iff they're my words.
 The bear eagerly wolfs down your food, after which he seems to calm
 down considerably and even becomes rather friendly.










Path: ucivax!gateway
From: [e-mail] ("Edward V. Wright")
Subject: Re:  Symantec Customer Service...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 19 Aug 91 14:57:53 GMT

I received both the C and Pascal upgrades in Friday.  (Turn-around time
of about a week, even though they told me to expect 3-4 weeks.  I did
not pay extra for special service and was not asked about it.)  Both
packages have the disks.  I also received notification of both upgrades
by mail, within a few days after they were announced.  I think that, for
the most part, Symantec is doing an excellent job with the upgrades, but that
doesn't rule out a few snafus.










Path: ucivax!gateway
From: [e-mail] (Piper Keairnes)
Subject: ThinkC 5.0 educational prices
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 19 Aug 91 22:14:00 GMT

The educational price for ThinkC 5.0 here at Purdue is $89.29 plus tax. Just
thought I'd let you all know.

_____
Piper Keairnes - Computer Science
INTERNET: [e-mail]
  BITNET: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: thanks,
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 20 Aug 91 16:48:33 GMT


hi all,

thanks to everyone who tried their darndest to figure out
what was wrong with my alerts.  it turns out (after much
too much debugging) that the code was 100% solid, but the
@!*%&^ resource map wasn't.  so after copying the resources
themselves into another file, all was well.

sorry to have wasted your time for such a trivial problem...

so here's another one!  what's the best way to blindly copy
all the resources from one file to another?

:jeff bellsey
[e-mail]










Path: ucivax!gateway
From: [e-mail] (David Sugar)
Subject: GrafPort Question
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 56
Date: 20 Aug 91 18:33:57 GMT


  I'm wokring on a function that is supposed to open an offscreen GrafPort,
then do some drawing on it, the use copybits to copy the off screen GrafPort
into a window.  The window and the GrafPort are the same size, and I think
that I have set everything up correctly.  I will attach the function and if
someone see's a problme could you mail me??  What the problem is, is that
when I do a copybits the window get's filles with 'garbage' basicly.  In
the function attachect it is just supposed to draw an 'X' in the window and
then copy it to the screen, but there is a lot of other stuff in the window
when it is copied.  Make sence??  I'm sure it's just something that I'm
forgetting to do, but the problem is that I'm not sure what that is..   Here
is what I have done...
Drawing2()
{
    DialogPtr        Dialog;
    int                XWidth,YWidth;
    long            top,bottom,left,right,Mem,RowLength;
    GrafPtr            Off;

    top=left=0;
    bottom=right=256;
    XWidth=right-left;
    YWidth=bottom-top;
    RowLength=XWidth/8;
    Mem=RowLength*YWidth;

    Dialog=GetNewDialog(Dilg,0L,-1L);
    ShowWindow(Dialog);
    Off=(GrafPtr) NewPtr(sizeof(*Dialog));
    OpenPort(Off);

    Off->portBits.rowBytes=RowLength;
    Off->portBits.baseAddr=NewPtr(Mem);
    SetRect(&Off->portBits.bounds,0,0,XWidth,YWidth);
    Off->portRect=Off->portBits.bounds;
    SetRectRgn(Off->visRgn,0,0,XWidth,YWidth);
    SetRectRgn(Off->clipRgn,0,0,XWidth,YWidth);

    BackPat(black);
    CopyBits(&Off->portBits,&Dialog->portBits,&Off->portRect,&Dialog->portRect,srcCopy,NULL);
    ForeColor(redColor);
    MoveTo(0,0);
    LineTo(256,256);
    MoveTo(0,256);
    LineTo(256,0);
    CopyBits(&Off->portBits,&Dialog->portBits,&Off->portRect,&Dialog->portRect,srcCopy,NULL);
}

Ok.  I think that everything is pretty straight forward in the function. I
have set up the normal stuff for that Mac before this so that's no problem
it compiles no problem, but like I said, when I do the
CopyBits functions it copies a lot of extra garbage that shouldn't be there.

David Sugar
[e-mail]
udsugar@129.25.7.100










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: thanks,
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 20 Aug 91 16:48:33 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 21 Aug 91 00:33:45 GMT

Jeff wrote:
   what's the best way to blindly copy all the resources from one file
   to another?

There's an example of an XCMD that does this in Mactutor, probably in
the last year.  The basic idea is to open the source and destination
files using HOpenRF (after creating the destination using Create), and
FSRead and FSWrite until you're done.  If you have the THINK
Reference, there's an example of a program that copies both forks of a
file in the entry for OpenRF.

Of course, if you have a trashed resource map, then you're out of
luck :-).

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Mark Hartman)
Subject: Re:  Questions??
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 28
Date: 21 Aug 91 17:22:44 GMT

David Sugar ([e-mail]) writes:

> I am using Think C, and I am trying to read and write from a resource
> that is in the application that I am working on. So, with ResEdit I
> made a resource called 'test' and I would like to be able to write an
> integer to this resource. So, I have variables, data is an int,
> data_ptr is a Ptr, and data_handle is a Handle, to make it easy. Then
> I assign data 300 but, when I assign *data_ptr=data; then *data_ptr =
> 44 now, that is my biggest problem, because then when I write the
> data to the resource with AddResource it saves it as 44, not 300.

One of the conceptual problems that most people have with Ptrs and Handles
is that they are *only* pointers to areas of information, but do not include
the implication that the area they point to actually exists!  In your example
above, data_ptr was probably some random value (remember, a Ptr is simply
a longword plucked out of memory and "blessed" to be a Ptr - it's not changed
automatically), so when you said "*data_ptr=data", some random memory loc
was overwritten with 300.  Further operations of your program or the Mac's
operating system changed the memory location to what you see as 44.

The simple declaration of a Ptr or a Handle does not allocate memory.  You
must first use the NewPtr and/or NewHandle calls to do so.  See Inside Mac
volume 2, "The Memory Manager" chapter.

Much good luck in your endeavors.

Mark Hartman
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Peter Miller)
Subject: Re: Questions??
X-Face: u\%{\QY_5[S37dfQ#c*#""=K,KGq>4wGryNm+=TT]1jOGap~>j*-sb9d|ll.sHIJu&n{:T`
 cP|e(B?o,W%l_)o5pW,"MVie?sw{hZ@7E^o`C:wz){1p!u%O<N#lcPP]b|f:2,-mNKt{Ue(_7e"ok@
 b".~TQ#YGrlY[r!:5q[/"O&Bn4:3mwuUFt>Qc]KTq}A")Jk,[
Message-ID: <[e-mail]>
In-Reply-To: Your message of 21 Aug 91 17:22:44 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 36
Date: 21 Aug 91 23:14:37 GMT


David Sugar ([e-mail]) writes:

> I am using Think C, and I am trying to read and write from a resource
> that is in the application that I am working on. So, with ResEdit I
> made a resource called 'test' and I would like to be able to write an
> integer to this resource. So, I have variables, data is an int,
> data_ptr is a Ptr, and data_handle is a Handle, to make it easy. Then
> I assign data 300 but, when I assign *data_ptr=data; then *data_ptr =
> 44 now, that is my biggest problem, because then when I write the
> data to the resource with AddResource it saves it as 44, not 300.


Ahem.  Has anyone noticed that 300 % 256 == 44?

If you look in MacTypes.h you will notice
    typedef char *Ptr;

Storing 300 into a byte will obviously lose data!
If you want to store a short, cast the pointer
    *(short *)data_ptr = 300;

@begin(WishMode)
Personally I think the typedef should should read "typedef void *Ptr;" so
that dereferencing an un-cast Ptr will always fail.
This way many potential problems are detected at compile time,
and also many system calls which take a Ptr argument will cease
to complain when I have "check pointer types" enabled,
(and doesn't everyone?)
@end(WishMode)

Regards
Peter Miller    UUCP    uunet!munnari!bmr.gov.au!pmiller
/\/\*        CSNET    [e-mail]
Disclaimer:  The views expressed here are personal and do not necessarily
    reflect the view of my employer or the views or my colleagues.










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Is it safe to increase the FOPEN_MAX limit ??
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 17 Aug 91 22:27:02 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 22 Aug 91 16:11:12 GMT

   I would like to increase the FOPEN_MAX limit from 15 to 20.  As far
   as I can tell there should be no problems.  The only thing that I
   can see that is materially affected by a change in FOPEN_MAX is the
   allocation :-

   FILE __file[FOPEN_MAX] ( iomisc.c )

   The datatype FILE is only 38 bytes, so I can't see that memory
   concerns should be a big deal.  The File Manager looks like it
   dynamic allocates what it needs ( I can't find a fixed limit for
   the max files anywhere).

Actualy, the File Manager has a fixed limit based on the length of the
FCB buffer.  Unlike the VCB queue, this buffer is allocated at boot
time, and is of fixed length.  I haven't found any doc to support
this, but I've heard that the System 7 File Manager will dynamically
reallocate the FCB buffer if more blocks are needed.  For info about
the FCB buffer (and it's affected by the boot blocks), see IM VI-178.

There are a couple shareware utilities which will let you change your
boot blocks to support more open files.  ("Bootman" is one.)

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: infoserv!apple!well![e-mail] (Bill Hofmann)
Subject: oConv barfs on UFailure.a.o
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 23 Aug 91 00:08:50 GMT

with message "Can't convert this file (10@684)".  This is kinda aggravating,
I just upgraded to THINK 5, and was hoping to be able to switch between
THINK and MPW easily.  What does this error mean, and is there a workaround?
I don't want to have to hand-code my own UFailure.a.

I must say that I'm quite happy with what's worked so far of THINK 5.  But
until I can run my project, ...

-Bill Hofmann










Path: ucivax!gateway
From: [e-mail]
Subject: Hot Key Source Code
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 23 Aug 91 18:12:19 GMT

I'd like to implement a hot key into an application I am writing, but this
is new territory for me.  I hate FKEYs, and I'm sure there must be a better
approach, anyway.  I'm guessing I will need to write an INIT code resource.
 Suggestions anyone?  Sample source code would be great, but I'll take
anything.  Thanks in advance,


-------------------------------------
- Richard Beecher ([e-mail]) -
--------------------------------------











Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: oConv barfs on UFailure.a.o
Message-ID: <[e-mail]>
In-Reply-To: Your message of "23 Aug 91 00:08:50 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
X-Mts: smtp
Date: 24 Aug 91 04:36:46 GMT

> I don't want to have to hand-code my own UFailure.a.

Did you look at the file "Exceptions.c", in the TCL Library folder?
It implements a very MacApp-like (*) exception handling mechanism,
with some pretty cool C++-like (*) macros to hide the complexity.

(*) Disclaimer:  I haven't actually used either MacApp or C++, but I
read a lot of manuals.

-- Russell S. Finn
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Jamie R. McCarthy")
Subject: Writing inline functions
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 20
Date: 25 Aug 91 04:12:39 GMT

Let me see if I understand page 125 of the version 4 user's manual.  I
have a few classes which have small methods that simply return a
constant.  Can I replace:

short CShowPane::getBorderWidth(void)
{
    return 1;
}

with something like:

short CShowPane::getBorderWidth(void) = { asm { move.w #0001,-(SP) } }

?  Or (1) does it only work with functions not methods, or (2) is it
not meant to work this way at all?
--
 Jamie McCarthy                    [e-mail]
 Disclaimer:  it's my responsibility iff they're my words.
 Alle diese Gleichnisse wollen eigentlich nur sagen, dass das Unfassbare
 unfassbar ist, und das haben wir gewusst.  -- Franz Kafka










Path: ucivax!gateway
From: [e-mail] (David Sugar)
Subject: Thanks
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 26 Aug 91 01:00:29 GMT


  First off, I would like to thank everyone who replied to my GrafPort question,
my problem was that I wasn't erasing the off screen port by calling
EraseRect(&Off->portRect);.  That solved my problem and it works fine now.
  I've been working on code which I would like to use either CGrafPort's or
an off screen graphic world.  I've been hacking around with both and havn't
gotten very far.  Does anyone have any opinions on which would be better for
doing fairly simple color aniamtion.  Basicly all I want to do is draw and
place pics on a off screen port and then use a copy bits to put it onto the
screen.  Also, does anyone know where I can get some good source for either
using CGrafPort's or a Graphics world.  And is a CGrafPort much different than
just a plain GrafPort.  So far I have sorta gotten it set up, but what it
does is when I open the port is opens it on the screen, which seems wierd to
me, but it's probabily something I'm doing wrong..
  I really do appreciate all the responces that I get from my questions.  I
am really learning a lot from reading the responces and others peole's questions
and hacking around in Think-C..  Thanks

David Sugar
udsugar@129.25.7.100











Path: ucivax!gateway
From: [e-mail] (Ephraim Vishniac)
Subject: freqDurationCmd synonym for noteCmd?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 26 Aug 91 15:19:36 GMT


In Think C 5.0, <sound.h> defines freqDurationCmd = 40, but
doesn't define noteCmd. I can't find freqDurationCmd in SpinSide
Mac, but it does give the value of noteCmd as 40. Is there some
naming skew here?










Path: ucivax!gateway
From: [e-mail] (Ephraim Vishniac)
Subject: Various Think C 5.0 oddities
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 40
Date: 26 Aug 91 18:53:25 GMT


Here are various oddities I've discovered in porting John Norstad's Sample
application from MPW to Think C 5.0. When I say "x should be y" in the
following list, my authority is the version of SpinSide Mac found on
"Desperately Seeking Seven." I don't have the ANSI C spec, so I'll avoid
making any definite claims on compliance issues.

In <Sound.h>, noteCmd isn't defined but should be = 40.

In a list of enumerated items, Think C complains of a syntax error if the
last item has a trailing comma. MPW doesn't complain. I don't know if ANSI
addresses this, but it's really a handy thing.

Think C complains of a syntax error if the closing brace of a function is
followed by a semicolon. MPW doesn't complain. Since certain kinds of
statements (such as declarations) are allowed outside functions, why not
allow a null statement?

In <Traps.h>, UnMountVol should be UnmountVol.

In <Notification.h>, nmIcon should be nmSIcon.

Inside Mac is inconsistent about hFileInfo and hfileInfo. MPW goes one way,
TC goes the other. It would be nice if Think C allowed either.

Think C considers arrayName and &arrayName to have different types. MPW
doesn't complain. I wouldn't care, myself, but John occasionally writes the
latter.

Think C refuses to cast lvalues. I always thought this was conventional C.
MPW allows it.

Cosmetic oversight: The compilation window should list files done and files
to go, since very few people have a good idea how many lines they're
compiling.

Many, many cosmetic oversights: I don't believe the User's Manual was ever
proofread by a native speaker of English (graduates of engineering schools
don't count). There are many instances of words missing or transposed in
the running text.










Path: ucivax!gateway
From: [e-mail] (Ephraim Vishniac)
Subject: Re: Various Think C 5.0 oddities
Message-ID: <[e-mail]>
In-Reply-To: Your message of "Mon, 26 Aug 91 15:43:48 CDT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 45
Date: 26 Aug 91 20:55:47 GMT


Not in reply to Russ' message, but following up my original, I'm told
that all of the discrepancies with Inside Mac that I complained about
are actually consistent with the latest MPW headers. Strange, but true.

Also, I've noticed that there are some all-lower-case routines
prototyped in <Resources.h> (addresource, for example) that appear to
be analogous to the mixed-case routines (e.g., AddResource) but use C
strings. Are these functions actually supplied in any of the libraries
or should I implement them myself using the supplied prototypes?

   Date: Mon, 26 Aug 91 15:43:48 -0500
   From: [e-mail] (Russell E. Donnan)

   >Think C refuses to cast lvalues. I always thought this was conventional C.
   >MPW allows it.

   This is also wrong on the part of MPW.  There aren't any implicit casts in
   ANSI.  There is implicit promotion, but not casts.

But I mean that you can't *explicitly* cast an lvalue. You can't say

    (foo_t *)blah = &foo;

Instead, you have to say

    blah = (blah_t *)&foo;

   >Many, many cosmetic oversights: I don't believe the User's Manual was ever
   >proofread by a native speaker of English (graduates of engineering schools
   >don't count). There are many instances of words missing or transposed in
   >the running text.

   I've ordered ThinkC 5, but haven't gotten in yet.  I hope that the documentation
   isn't as poor as it sounds.

Actually, the documentation is pretty good and very extensive. The
User Manual is about the same size as before (548pp.) even though all
the info on object-oriented programming has been removed to a separate
Object-Oriented Programming Manual (528pp.). The Standard Libraries
Reference has grown about 50%, to 340 pages.

Still, in the couple hundred pages of the User Manual that I've
browsed, I've found enough errors to be slightly annoyed.











Path: ucivax!gateway
From: [e-mail] ("Russell E. Donnan")
Subject: Re:  Various Think C 5.0 oddities
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 52
Date: 26 Aug 91 21:00:08 GMT

These have been reordered to organize my own thought.  Apologies to
Ephraim.

>Think C considers arrayName and &arrayName to have different types. MPW
>doesn't complain. I wouldn't care, myself, but John occasionally writes the
>latter.

These *ARE* two different things.  arrayName is a pointer to an
array.  &arrayName is a pointer to the first element of an array,
equivalent to &arrayName[0].  As an example of the difference, the
sizeof macro will return the whole size for the first, and the size of
the first element for the second.  The difference is inherent in the
language so that pointer arithmetic works properly.

>Think C refuses to cast lvalues. I always thought this was conventional C.
>MPW allows it.

This is also wrong on the part of MPW.  There aren't any implicit casts in
ANSI.  There is implicit promotion, but not casts.

The following are OK in ANSI.  They are just style questions.  I haven't
personally run into these because I happen to code in the style expected
by ThinkC, I guess.

>In a list of enumerated items, Think C complains of a syntax error if the
>last item has a trailing comma. MPW doesn't complain. I don't know if ANSI
>addresses this, but it's really a handy thing.
>
>Think C complains of a syntax error if the closing brace of a function is
>followed by a semicolon. MPW doesn't complain. Since certain kinds of
>statements (such as declarations) are allowed outside functions, why not
>allow a null statement?

>Cosmetic oversight: The compilation window should list files done and files
>to go, since very few people have a good idea how many lines they're
>compiling.

Yeah, I would like to see this changed also.

>Many, many cosmetic oversights: I don't believe the User's Manual was ever
>proofread by a native speaker of English (graduates of engineering schools
>don't count). There are many instances of words missing or transposed in
>the running text.

I've ordered ThinkC 5, but haven't gotten in yet.  I hope that the documentation
isn't as poor as it sounds.

-Russ
---
Russ Donnan, [phone], [e-mail]
Convex Computer Corporation, 3000 Waterview Parkway, Richardson, TX, USA
Vs lbh pna ernq guvf, guvax nobhg vg.  Lbh'er n areq zna...










Path: ucivax!gateway
From: [e-mail] (Jonas Barklund)
Subject: Various Think C 5.0 oddities
Message-ID: <[e-mail]>
In-Reply-To: Ephraim Vishniac's message of 26 Aug 91 20:55:47 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 27 Aug 91 07:21:52 GMT

Ephraim,

My Harbison & Steele (3rd ed) tells me that the result of a cast is never an
lvalue in ANSI C. Since you can, in all reasonable contexts, cast the rvalue
instead, this does not seem to be much of a restriction.

-- Jonas Barklund, Uppsala Univ.










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: TC4.0.5 slowdown with RAM cache
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 27 Aug 91 10:36:39 GMT

[You may have seen this before: an MMDF mail problem meant that all my
 outgoing mail for the last three days was dropped on the floor.
 This is a recorded announcement.
]

I notice that a large RAM cache really slows down TC4.0.5. After compiling
each file, it writes a huge amount of stuff to disk, a process which can
take many times longer than the compilation run. This delay seems related
to RAM cache size: the smaller the cache, the shorter the delay. Why is TC
taking this performance hit? With an 8Meg machine, I'd quite like to keep
the RAM cache quite big.

Configuration: SE/30, System 7.0.

        Nick.











Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Symantec Customer Service...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 27 Aug 91 10:36:45 GMT

[You may have seen this before: an MMDF mail problem meant that all my
 outgoing mail for the last three days was dropped on the floor.
 This is a recorded announcement.
]

>I also received notification of both upgrades
>by mail, within a few days after they were announced.

Anybody heard of upgrade notifications outside the US yet? I've heard
nothing.

Btw, Apple UK has just (as of this week) announced System 7.0.


        Nick.











Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: THINK C and THINK Pascal Press Release
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 27 Aug 91 10:36:41 GMT

[You may have seen this before: an MMDF mail problem meant that all my
 outgoing mail for the last three days was dropped on the floor.
 This is a recorded announcement.
]

>The THINK Class Library provides the building blocks for a
>standard Macintosh user interface such as windows, menus and
>controls.

The $64 question is: how compatible is the "new" Class Library with the
4.0.x Class Library? Even though I haven't actually altered any of the TCL
sources (beyond the 4.0.5 upgrades) my code is tied to the "old" class
library, in particular the particularities of its behaviour (as we all
know, OO programming involves lots of side-effects and order-dependent
stuff). If, for example, windows are deactivated in a different order in
the new TCL when an application quits, I could be in trouble.

        Nick.











Path: ucivax!gateway
From: [e-mail] (Ephraim Vishniac)
Subject: Think C 5.0 oddities, summary of discussion
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 27 Aug 91 13:16:00 GMT


My thanks to everybody who helped illuminate the minor problems I
encountered while converting to Think C 5.0. For anyone who didn't
follow the discussion, here's an executive summary:

1. Discrepancies between SpInside Mac and Think C are moot, because
Think C now uses the same header files as MPW. MPW's correctness in
the matter of header files is, of course, divinely ordained. Inside
Mac is now the Old Testament, and MPW the new one.

2. In each case where Think C complained about constructions which MPW
accepted, Think C is ANSI-conformant and MPW is not. Perhaps Think C
is still more divine than MPW, but this depends on your view of the
ANSI committee.











Path: ucivax!gateway
From: [e-mail] (Brady Duga)
Subject: arrayname and &arrayName
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 27 Aug 91 13:56:32 GMT

>
> >Think C considers arrayName and &arrayName to have different types. MPW
> >doesn't complain. I wouldn't care, myself, but John occasionally writes the
> >latter.
>
> These *ARE* two different things.  arrayName is a pointer to an
> array.  &arrayName is a pointer to the first element of an array,
> equivalent to &arrayName[0].  As an example of the difference, the
> sizeof macro will return the whole size for the first, and the size of
> the first element for the second.  The difference is inherent in the
> language so that pointer arithmetic works properly.
>

This may just have been a typo, but &arrayName is not equivalent to
&arrayName[0]. &arrayName[0] is a pointer to the first element of an
array and is equivalent to arrayName. According to K&R, 2nd ed. (p99):
"...pa=&a[0] can also be written as pa=a" (This is also in the 1st ed.,
p94). &arrayName should then be the pointer to the pointer to the
beginning of the array. However, I don't know if it's a legal statement.
In K&R 1st ed. they say "...an array name is a constant, not a variable:
constructions like a=pa or a++ or p=&a are illegal." The 2nd ed. says:
"...an array name is not a variable; constructions like a=pa and a++
are illegal." So what's the deal? is &arrayName legal in ANSI C?

--Brady ([e-mail])











Path: ucivax!gateway
From: [e-mail] ("Povl H. Pedersen")
Subject: Think C 5.0 oddities (I have been looking it up)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-Vms-To: IN::"[e-mail]"
Lines: 33
Date: 27 Aug 91 16:23:42 GMT
X-Envelope-To: [e-mail]


About the enum construct, I have been looking up in Stroustrup's book
(The C++ Programming Language, but the old version though) (He is a dane
like me too ;-) ).  I am not sure if this also counts for ANSI C, but
I am very sure that it is OK for K&R:

enum is defined this way:
enumlist, enumElement
THIS MEANS NO TRAILING COMMA ALLOWED. But this may be outdated information.

About casting lvalues I have been thinking a bit, look at the following
piece of C code. How would it work without casting lvalues ?

void *myPtr;
int a[10];
char b[20];

myPtr=a;
((int *) myPtr)[3] = 7;       // myPtr[3] = 7  does not know how much to store
myPtr=b;
((char *) myPtr)[11] = 'A';   // here we store a different quantity

So, WHENEVER YOU USE VOID * IT IS NECESARY TO CAST LVALUES,
But if void * some way is forbidden in Think C 5.0 (or ANSI), then it
is not necesary to let a casted lvalue become an lvalue. (But this is
even worse than the bug mentioned (not allowing casting)). You may ignore
the index [] above in the assignments if you prefer. You can also imagine
myPtr pointing to some structure.

So this seems to be a 1-1 draw in the fight THINK C 5.0 vs. THE STANDARD.
Somebody please check if casting a void * lvalue is legal.

Povl H. Pedersen      [e-mail]










Path: ucivax!gateway
From: bootsie![e-mail] ("Eric K. Olson")
Subject: Compatibility with old class library
Message-ID: <[e-mail]>
X-Mailer: Mail User's Shell (6.4 2/14/89)
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 34
Date: 27 Aug 91 21:52:06 GMT

In a message of Aug 27, 10:36am, Nick writes:
>
> The $64 question is: how compatible is the "new" Class Library with the
> 4.0.x Class Library? Even though I haven't actually altered any of the TCL
> sources (beyond the 4.0.5 upgrades) my code is tied to the "old" class
> library, in particular the particularities of its behaviour (as we all
> know, OO programming involves lots of side-effects and order-dependent
> stuff). If, for example, windows are deactivated in a different order in
> the new TCL when an application quits, I could be in trouble.

I will be posting a set of Weaver documents that update the Think Class
Library 1.0 to work with the new compiler (and with all type checking
turned on).  This same set of patches also adds some functionality
needed to use the Prepare() View Editor with the classes, and fixes a
few other real bugs in the old (1.0) Think Class Library.

This set of patches will let you continue with the old class library
if you wish.  The current issue of Prepare() (due out this week) works
with either compiler; the issue after that will require the new compiler
and class library.

I expect to post the patch within the week.  It is freely redistributable.

Cheers!

-Eric



--
Eric K. Olson, Editor, Prepare()      NOTE:     [e-mail] doesn't work
Lexington Software Design             Internet: [e-mail]
72A Lowell St., Lexington, MA  02173  Uucp:     harvard!endor!olson
[phone]                        Bitnet:   OLSON@HARVARD










Path: ucivax!gateway
From: [e-mail] (Adam Schabtach)
Subject: Sys 7 Sound Mgr?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 28 Aug 91 04:37:55 GMT

Has anyone tried using the Sound Manager routines under System 7? I've
just spent an hour trying to get the simplest code to run, with little
success. I can allocate a channel, but only if I do the memory
allocation myself (IM VI says that SndNewChannel can do it for me, if
I want). After that, everything I try results in an error code of -205
("Channel is corrupt or unusable"). Even if I just allocate the
channel and immediately call SndDisposeChannel, I get that error code.

Help! If I can't get this to work, I guess I'll have a stab at the old-
fashioned Sound Driver routines...

Thanks,
--Adam











Path: ucivax!gateway
From: [e-mail] (Harald Hanche-Olsen)
Subject: Think C 5.0 oddities (I have been looking it up)
Message-ID: <[e-mail]>
In-Reply-To: "Povl H. Pedersen"'s message of 27 Aug 91 16:23:42 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 36
Date: 28 Aug 91 09:06:08 GMT

Povl H. Pedersen <[e-mail]> writes:

   I am not sure if this also counts for ANSI C, but
   I am very sure that it is OK for K&R:

   enum is defined this way:
   enumlist, enumElement
   THIS MEANS NO TRAILING COMMA ALLOWED. But this may be outdated information.

Accepting trailing commas is new in ANSI C.

   About casting lvalues I have been thinking a bit, look at the following
   piece of C code. How would it work without casting lvalues ?

   void *myPtr;
   int a[10];
   char b[20];

   myPtr=a;
   ((int *) myPtr)[3] = 7;       // myPtr[3] = 7  does not know how much to store
   myPtr=b;
   ((char *) myPtr)[11] = 'A';   // here we store a different quantity

   So, WHENEVER YOU USE VOID * IT IS NECESARY TO CAST LVALUES,

Ah, but you are not casting an lvalue here, you are merely using a
cast to define the lvalue, which is another thing altogether.
((int*)myPtr)[3] is equivalent to *((int*)myPtr+3), and the (int*)
here both serves to make sure the pointer arithmetic comes out right
and to make ((int*)myPtr+3) come out as (int*), so the compiler can
know how much to store.  No sweat.
--
Harald Hanche-Olsen <[e-mail]>               I eat my peas with honey
Division of mathematical sciences                      I've done it all my life
The Norwegian Institute of Technology             It makes the peas taste funny
N-7034 Trondheim NORWAY                          But it keeps them on the knife










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Compatibility with old class library
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 22
Date: 28 Aug 91 10:14:09 GMT

>I will be posting a set of Weaver documents that update the Think Class
>Library 1.0 to work with the new compiler (and with all type checking
>turned on).

I'm not sure I want to adopt this as a solution. If Symantec are
maintaining the TCL through revisions of the compiler (and more
importantly, the System Software) I'd rather move with that. So, it's the
backward compatibility that concerns me. I have several tens of thousands
of lines of code which I've based on the old TCL (all done by inheritance
from the original TCL classes, rather than alterations to TCL sources).
Will this port immediately to the new TCL? Even if it requires a little
work (different class names and so on) then that's not too bad (although
it's going to discourage developers from relying on it if each new revision
means altering their sources). The real nightmare scenario is that the
internal workings of the TCL have altered so that my application compiles
but the different execution dependencies of the TCL now mean it bombs out
due to dangling pointers and so on.

OOP is a real pig's ear, isn't it folks? :-)

        Nick.











Path: ucivax!gateway
From: [e-mail] (Chris McNeil)
Subject: Notification Manager bus error
Message-ID: <[e-mail]>
X-Mailer: QuickMail/SMTP interface.
Newsgroups: fa.think-c
Lines: 48
Date: 28 Aug 91 12:44:36 GMT

I want to put up a notifyication when an error occurs in a background
application I'm writing. I then want to wait until the uses responds to the
notification and exit the program. This is my first try at writing a response
procedure. The following code gives me a bus error, anyone out there willing to
tell me what STUPID thing I'm doing wrong ?

Chris McNeil
[e-mail]



#define nil 0L
#include <OSUtil.h>
int test=1;
main()
{
long errCode=0;
EventRecord myEvent;
char* junk="\phello chris";
QElemPtr trythis;
int err;
struct NMRec    myNote;
pascal void MyResponse ();

    myNote.qType = nmType;    /* queue type -- nmType = 8 */
    myNote.nmMark = nil;        /*no mark in Apple menu */
    myNote.nmSIcon =nil ;        /* flashing Icon */
    myNote.nmSound = nil;    /* no sound to be played */
    myNote.nmStr =(StringPtr)"\phello";        /* alert box */
    myNote.nmResp =(ProcPtr)MyResponse;        /* response procedure */
    myNote.nmRefCon =  SetCurrentA5();    /* set to my A5*/
err = NMInstall ((QElemPtr) &myNote);
for (;;){
GetNextEvent(everyEvent, &myEvent);
if (test == 132){
err=NMRemove ((QElemPtr) &myNote);
break;
}
}
}
pascal void MyResponse (QElemPtr nmReqPtr)
{
unsigned long oldA5;
 oldA5 = SetA5((*(NMRec *)nmReqPtr).nmRefCon);
    test = 132;
  SetA5(oldA5);

}










Path: ucivax!gateway
From: [e-mail] (David Sugar)
Subject: System 7 Sound's
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 25
Date: 28 Aug 91 14:49:14 GMT


  I would have mailed this right back to whom ever sent it, but I lost the
address when I lost my connection suddenly.  Anyway..
  With SndNewChannel you have to first assign mySndChan to be NULL before
you make the SndNewChannel call.  Well, that's the easiest way to do it,
then SndNewChannel will allocate enough space for the sound.  Or, you can
assign mySndChan a length to be allocated.  I guess it depends on what
you are trying to do.
  I did something like this, with no problem..

Sound()
{
    SndChannelPtr    soundChannel;

    soundChannel=0L;
    SndNewChannel(&soundChannel,sampledSynth,initMono,0L);
}

And the you can call the SndPlay to play the sound..

Hope this helps.

David Sugar
[e-mail]











Path: ucivax!gateway
From: bootsie![e-mail] ("Eric K. Olson")
Subject: Old TCL, new Compiler
Message-ID: <[e-mail]>
X-Mailer: Mail User's Shell (6.4 2/14/89)
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 26
Date: 28 Aug 91 17:44:03 GMT

In your message of Aug 28, 10:14am, you write:
>
> >I will be posting a set of Weaver documents that update the Think Class
> >Library 1.0 to work with the new compiler (and with all type checking
> >turned on).
>
> I'm not sure I want to adopt this as a solution.

I only suggest this as a short-term, interim solution.  Originally I did
it because I thought the issue of Prepare() would be released before
THINK C 5 (and I wanted to make sure my code would work with the new
compiler when released).  It may be useful for some people as an interim
solution.

I don't plan on using it for more than a few more days myself!

Cheers!

-Eric


--
Eric K. Olson, Editor, Prepare()      NOTE:     [e-mail] doesn't work
Lexington Software Design             Internet: [e-mail]
72A Lowell St., Lexington, MA  02173  Uucp:     harvard!endor!olson
[phone]                        Bitnet:   OLSON@HARVARD










Path: ucivax!gateway
From: [e-mail] (Rob Zanconato)
Subject: Please remove me from this list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 28 Aug 91 18:59:39 GMT


Pleas remove me from the think-c list, thanks.
Roberto Zanconato: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Prepare()
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 28 Aug 91 19:39:39 GMT


I have heard a bit about Prepare(). I would like
to have some more information about it and
how to get it and how much it costs.

Im using Think C 4.0.5 and my upgrade to 5.0 is on the mail.


Thanks a lot.












Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: TC5.0 release in the UK
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 29 Aug 91 18:01:17 GMT

In case anybody's interested, I've just been on the line to Symantec UK.
They don't have any clear details about the TC5.0 release yet, but reckon
it'll be 4-6 weeks before they get it. They don't know the upgrade price
either.

Seems about in step with Apple UK who've had System 7.0 kits available for,
ooh, an entire week now...

        Nick.











Path: ucivax!gateway
From: [e-mail]
Subject: Prepare()
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 29 Aug 91 18:03:23 GMT

Speakig of magazines like Prepare(), has anyone seen a copy of Splash
lately?  After we subscribed, I got one issue and that's it, and that was
osmetime ago.

Mike Nowak.
U-M ITD Office of Instructional Technology










Path: ucivax!gateway
From: [e-mail] (Hobbes)
Subject: Splash
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 29 Aug 91 21:04:42 GMT

The reply I got ~1 week ago from splash@applelink was that they are (seriously)
behind, but the new issue should be out by the end of this month (August).
There have only been two issues put out so far.  What this means is that a
four-issue subscription will last a while longer than 1 year.

Hobbes, [e-mail]










Path: ucivax!gateway
From: [e-mail] (Peter Miller)
Subject: Re: Various Think C 5.0 oddities
X-Face: u\%{\QY_5[S37dfQ#c*#""=K,KGq>4wGryNm+=TT]1jOGap~>j*-sb9d|ll.sHIJu&n{:T`
 cP|e(B?o,W%l_)o5pW,"MVie?sw{hZ@7E^o`C:wz){1p!u%O<N#lcPP]b|f:2,-mNKt{Ue(_7e"ok@
 b".~TQ#YGrlY[r!:5q[/"O&Bn4:3mwuUFt>Qc]KTq}A")Jk,[
Message-ID: <[e-mail]>
In-Reply-To: Your message of 26 Aug 91 18:53:25 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 32
Date: 29 Aug 91 22:57:17 GMT


Ephraim Vishniac <[e-mail]> writes:
> In a list of enumerated items, Think C complains of a syntax error if the
> last item has a trailing comma. MPW doesn't complain. I don't know if ANSI
> addresses this, but it's really a handy thing.
The ansi standard explicitly disallows it.
Personally, I think the standard got this wrong (prior art, one of the standard
committee's yardsticks, would indicate it should be allowed).

> Think C complains of a syntax error if the closing brace of a function is
> followed by a semicolon. MPW doesn't complain. Since certain kinds of
> statements (such as declarations) are allowed outside functions, why not
> allow a null statement?
That semicolon is actually a completely empty variable declaration,
and is explicitly disallowed by the ansi standard.

> Think C refuses to cast lvalues. I always thought this was conventional C.
> MPW allows it.
It aint convetional C, some compilers have a bug.
For you guys who have no idea what this is, consider
    short    foo;
    (long)foo = 123456789;
is not ansi conforming (and is rarely understood, anyway), while
    *(long *)&foo = 123456789;
is the "portable" and ansi conforming way to do it.
The ansi standard says the result of a cast is ALWAYS an rvalue.

Regards
Peter Miller    UUCP    uunet!munnari!bmr.gov.au!pmiller
/\/\*        CSNET    [e-mail]
Disclaimer:  The views expressed here are personal and do not necessarily
    reflect the view of my employer or the views or my colleagues.










Path: ucivax!gateway
From: [e-mail] (Kirk Swenson)
Subject: Re:  Splash
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 29 Aug 91 23:09:10 GMT

I've never seen a copy of Splash.  Is it useful?  What sorts of
information does it contain?  I'm always interested in sources of
useful programming information, but I don't know much about this
one.  Anyone out there want to share their experience with it?

Kirk Swenson
Berkeley, CA
[e-mail]











Path: ucivax!gateway
From: [e-mail] (Adam Schabtach)
Subject: Sound Manager revisited
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 30 Aug 91 01:15:56 GMT

Thanks to everyone who offered sound advice (heh) on my troubles with
the Sound Manager. I'm not quite sure what I was doing wrong, but
after reading the various responses to my plea, I had another go at it
and got it to work.

And I promise I won't use the Sound Driver (even though it did work on
my first attempt to use it, on a IIci running System 7, which is more
than I can say for the Sound Manager). :-)

Thanks again,
--Adam











Path: ucivax!gateway
From: [e-mail] ("James D. Meiss")
Subject: Re: Various Think C 5.0 oddities
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 25
Date: 30 Aug 91 04:24:22 GMT


Peter Miller <[e-mail]> writes (on casting lvalues):

>For you guys who have no idea what this is, consider
>    short    foo;
>    (long)foo = 123456789;
>is not ansi conforming (and is rarely understood, anyway), while
>    *(long *)&foo = 123456789;
>is the "portable" and ansi conforming way to do it.


        I'm sorry to be so obtuse, but could someone please explain this?
You are overwriting memory when you do this aren't you? Why in the world
would you want to do such a thing?


    James D. Meiss
    Applied Mathematics                   [phone] secretary
    University of Colorado

    [e-mail]

            [working at home  VOICE OR FAX # [phone]].












Path: ucivax!gateway
From: [e-mail] ("Gary T. Czychi")
Subject: TCL: Changing TextEdit fields on 'TAB'?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: THINK-C
Lines: 31
Date: 30 Aug 91 12:35:04 GMT
X-Envelope-to: [e-mail]



Hi,

in my AppMaker generated code for my main window (CMainWindow) which
is a Subclass of CWindow, I have defined several TextEdit fields.

Now, I want to jump from field to field when the user types a 'TAB' or
a 'CR'.

To do this, I have created a new method in my main window class,
CMainWindow.DoKeyDown, which overrides the original DoKeyDown method
(found in CBureaucrat, the ancestor of CWindow).

However, this doesn't work. Neither my method is called nor DoKeyDown
in CBureaucrat.

What do I do wrong? I have no idea. Can you please help me?


Thanks a lot.

  Gary

    Gary T. Czychi          University of St.Gallen

       [e-mail] (preferred host)
         czychi at csghsg52   (=bitnet)
           [e-mail]
             Switzerland
              -










Path: ucivax!gateway
From: [e-mail] (Kerry 'UPE' Cianos)
Subject: Editable test field
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 20
Date: 30 Aug 91 14:24:31 GMT
X-Envelope-to: [e-mail]

  Hi all,

    I've just started delving into Mac programming.  I have v5.0 of Think C
(upgraded from v4.05) and have been doing fairly well so far.  Here's
my question: I want to display a dialog with a TextEdit field (I think?)
and allow the user to enter say a number (like 135).  When the user presses
Return I want to get that number.  Is there an easy way to do this?  I made
a DLOG and a TextEdit DITL, called IsDialogEvent() and then whole 9 yards
but when I hit return it justs adds a CR to the text.  What I need is a way
to act on that Return.  I was hoping I wouldn't have to write a key parser
but I have this feeling... any comments (and especially source code!) would
be appreciated.  Thanks,

        - Kerry

  ------------------------------------------------------------------------
  Kerry Cianos, President                PS/2 = PS divided by 2 =
  Impress Technologies                   half a computer, thats ok, OS/2
  Email : [e-mail]           is only half an operating system!











Path: ucivax!gateway
From: [e-mail] (Bob Beason)
Subject: Editable text field
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 7
Date: 30 Aug 91 17:14:57 GMT
X-Envelope-to: [e-mail]

Hi Kerry,
Depending on what your dialog looks like, may dialog item #1 the OK button,
which is the default when you hit the CR. The text field can be a higher
item #.  That is what I have used in the past and it has worked fine.

Bob Beason
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Daniel Edward Rudman)
Subject: Re: Editable test field
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 31 Aug 91 08:02:18 GMT


You're messing up TextEdit, for one thing. Actually, all you need is a DLOG
with an Edit Text item (say, item #2) and an OK button (say, item #1). Then,
you do the standard ModalDialog but with a ProcPtr to some procedure, say
MyProcPtr (). Read IM Volume I for information on how to do this. If you
can, THINK Reference is even better.

In any case, the ProcPtr should check to see if return was hit and send
back an item number of 1 (the OK button) regardless of the context. At
least, that
is what you are asking for.

Hope this helps!

//Dan

P.S. TextEdit is a separate thing...











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: TCL: Changing TextEdit fields on 'TAB'?
Message-ID: <[e-mail]>
In-Reply-To: "Gary T. Czychi"'s message of 30 Aug 91 12:35:04 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 33
Date: 31 Aug 91 19:21:47 GMT

   From: "Gary T. Czychi" <[e-mail]>
   In my AppMaker generated code for my main window (CMainWindow)
   which is a Subclass of CWindow, I have defined several TextEdit
   fields.

   Now, I want to jump from field to field when the user types a 'TAB'
   or a 'CR'.

   To do this, I have created a new method in my main window class,
   CMainWindow.DoKeyDown, which overrides the original DoKeyDown
   method (found in CBureaucrat, the ancestor of CWindow).

   However, this doesn't work. Neither my method is called nor
   DoKeyDown in CBureaucrat.

If you have an active CEditText pane (ie, it's got a blinking cursor,
all typing goes there), the it's the current gGopher.  Therefore, it
will receive all typed keys, and will process them (unless they're
command-key sequences).  If you want to modify the behavior of the tab
key, you'll have to subclass the CEditText class to special-case the
tab key.

With the TCL 1.1 (included with Pascal 4.0 and C 5.0), there's a class
called CDialogText which catches tab keys and hands them off its
supervisor, which is presumably a CDialog.  This allows the CDialog to
decide which pane should be the next gopher, and to transfer control
properly.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Kerry 'UPE' Cianos)
Subject: EditText Item for Modeless
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 35
Date: 31 Aug 91 20:09:39 GMT
X-Envelope-to: [e-mail]

|>You're messing up TextEdit, for one thing. Actually, all you need is a DLOG
|>with an Edit Text item (say, item #2) and an OK button (say, item #1). Then,
|>you do the standard ModalDialog but with a ProcPtr to some procedure, say
|>MyProcPtr (). Read IM Volume I for information on how to do this. If you
|>can, THINK Reference is even better.
|>
|>In any case, the ProcPtr should check to see if return was hit and send
|>back an item number of 1 (the OK button) regardless of the context. At
|>least, that
|>is what you are asking for.
|>
|>Hope this helps!
|>
|>//Dan
|>
|>P.S. TextEdit is a separate thing...
|>

   Ok, but how would I do this from a modeless dialog.  You see, I want to
place a modeless dialog on the middle of the screen, and be able to pick
menus etc.  I also want the dialog to be able to accept a number and my
program process this.  Sorta like a rolodex.  You should be able to type in
the number and hit return, then other fields in the dialog would be updated
accordingly.  I've made a modeless dialog, with a TextEdit item.  But
again, when I hit return it actually does a CR.  I'll look into IM I and
see what I can deduce.  Another question?  Is it better too this in a
window and make controls for the stuff I need??  Or should I stick with the
Dialog??  Can anyone make heads or tails of this??  Thanks...

      Kerry

  ------------------------------------------------------------------------
  Kerry Cianos, President                PS/2 = PS divided by 2 =
  Impress Technologies                   half a computer, thats ok, OS/2
  Email : [e-mail]           is only half an operating system!